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[57] ABSTRACT 

A VOD scheduler maintains a queue of pending perfor- 
mance for each video. Using the notion of queue selection 
factor, a batching policy is devised that schedules the video 
with the highest selection factor. Selection factors are 
obtained by applying discriminatory weighting factors to the 
adjusted queue lengths associated with each video where the 
weight decreases as the popularity of the respective video 
increases and the queue length is adjusted to take defection 
into account 

17 Claims, 3 Drawing Sheets 
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MAXIMUM FACTOR SELECTION POLICY 
FOR BATCHING VOD REQUESTS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

Hie present invention relates the scheduling of perfor- 
mance requests in Video-On-Demand (VOD) systems. 

2. Background of the Invention 

In Video-on-Demand systems, popular videos (i.e. movies 
or other programs) are often requested by many viewers. In 
order to increase system throughput, some viewers request- 
ing an identical video may be transmitted (and hence share) 
a single video stream. This is referred to in the art as 
•hatching". 

Depending upon the system load, a requested video may 
not be started immediately. While viewers will usually 
tolerate a small wait time, a long wait may result in the loss 
(or "defection") of viewers. This may be accomplished, for 
example, by the viewer indicating (either actively or 
passively) that he is no longer interested in viewing the 
requested video. 

A conventional approach to video scheduling is the use of 
a first-come-first-serve (FCFS) policy. Under this policy, all 
video requests are placed in a single request queue. The 
request at the front of the queue is sewed when system 
capacity is available to service the request If batching is 
supported, all subsequent queued requests for the same 
video as the serviced request are also serviced from the same 
signal stream. 

An alternative to the above approach is to maintain a 
separate request queue for each video and to select the video 
with the longest queue for the next showing. This is referred 
to as the longest queue length first (LQF) policy. Still 
another approach is to provide periodic showing (say every 
5 minutes) for the most popular videos. For requests which 
would not be serviced by periodic showings, another sched- 
uling scheme such as FCFS can be used. 

As mentioned above, a viewer with a waiting request may 
defect if the waiting time exceeds the viewer's tolerance. 
Viewer defection is, of course, undesirable. The choice of 
video scheduling policy can have a significant effect on the 
amount of batching and defection. The FCFS policy does not 
take into account the batch size. By contrast, the LQF policy 
ignores the wait tune already incurred by the waiting 
requests. Periodic showing (when used alone) may not 
provide the flexibility needed to cope with dynamic load 
variations. 

Recently, a new approach oil batching was proposed in 
Shachnai, H., and Yu, P., The Role of Wait Tolerance in 
Effective Batching: A Paradigm for Multimedia Scheduling 
Schemes, IBM Research Report RC 20038, Apr. 1995, 
which is incorporated herein by reference. Under this 
approach, the additional wait time that viewers will tolerate 
before defecting, in addition to a video's respective queue 
length, is considered in making scheduling decisions. When 
system capacities become available, rather than scheduling 
the video immediately, the scheduler delays transmission of 
the video until just prior to expiration of the maximum wait 
tolerance time of the longest waiting one of the pending 
transmission requests. In the interim, additional requests for 
transmission of the video may join the queue, In contrast 
with LQF, a video with the longest queue may not get 
scheduled if all waiting requests are fairly recent This 
prevents the most popular videos from monopolizing the 
stream capacities. In contrast with FCFS, better batching is 
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achieved. To effectively implement this algorithm, however, 
knowledge of viewer tolerance is required. This knowledge 
may not be readily available. 

5 SUMMARY OF THE INVENTION 

A VOD scheduler maintains a queue of pending perfor- 
mance for each video. Using the notion of queue selection 
factor, a batching policy is devised that schedules the video 
with the highest selection factor. Selection factors are 
10 obtained by applying discriminatory weighting factors to the 
adjusted queue lengths associated with each video where the 
weight decreases as the popularity of the respective video 
increases and the queue length is adjusted to take defection 
into account 

15 Two alternative means of obtaining queue selection fac- 
tors are provided. Hie first approach, referred to as the 
steady state approach, is designed for quasi static or steady 
state environments where the relative request frequencies of 
the different videos changes very gradually (in terms of 

20 hours). The second approach, referred to as the instanta- 
neous approach, is for a more dynamic environment where 
the relative request frequencies of the different videos 
change rapidly (in terms of minutes). 
Under the steady state approach, the queue selection 

25 factor of a video is obtained by dividing the adjusted queue 
length of the video's associated queue by the square root of 
its relative request frequency. To account for the effect of 
detection, the queue length is adjusted by the number of 
defections. That is to say mat the scheduler substitutes the 

30 queue length in the selection factor calculation by the 
number of requests for a video since the last time that it was 
scheduled. Thus, for example, if a large percentage of the 
viewers corresponding to unpopular videos defect anyway, 
then using the number of requests since last scheduling 

35 (instead of the queue length) increases the fairness of the 
system. 

One way of estimating the relative frequency is to use a 
moving window estimate. This is obtained by counting, for 

^ each video, the number of requests which had occurred in a 
moving window of the immediate past (for example, a 
window of the past hour). Smoothing techniques can also be 
applied to take weighted averages over past estimates. 
Since unpopular videos have respectively lower relative 

45 request frequencies, the square roots of the inverse of their 
relative frequencies are larger than those of the popular 
videos. Thus, the queue selection factors are obtained by 
applying discriminatory weighting factors to the adjusted 
queue lengths which serves as a bias against the more 

5Q popular videos. This prevents popular videos from monopo- 
lizing all the stream capacities and forming frequent batches 
of small sizes (which is what occurs using the LQF policy). 

Under the instantaneous approach, the queue selection 
factor of a video is obtained by multiplying its adjusted 

55 queue length by the time which has elapsed since the last 
scheduling of the video. Although unpopular videos have 
lower request frequencies or shorter queues, their selection 
factors will increase as the time elapsed since last scheduling 
increases. This again provides Discriminatory weighting 

50 factors which disfavor the more popular videos. 

DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a block diagram of a multimedia server, 
FIGS. 2A-2B are flow charts of events handled in the 
65 Maximum Selection Factor (MSF) scheduler; and 

FIG. 3 is a flow chart of a video request handled by the 
MSF scheduler. 
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DETAILED DESCRIPTION OF A PREFERRED Two alternative means of obtaining queue selection factor 

EMBODIMENT are provided. The steady state approach is designed for a 

FIG. lisablockdiagramof a video server 100 in which ^J^Z^^^^f^^ 

video data (movies orottier moving visual or audio visual fr f J qu . encies f °[ 2f*. e * **** very 

, v . . . . , T. , V«« «• ™,™7 « gradually (in terms of hours). The instantaneous aurffoach is 

Si ^^°\™tl S ^^dtote to a moW dynamic environment where theTekK^ 

end client stations 103 over network 104 upon request Hie fluencies of the different videos can change rapidl? (in 

video server 100 also includes disks (not shown) which store tex ^ iS 0 f nwmite«) 

working data and the program code for the video server 100. Under m e ^dy state approach, the queue selection 

Other storage devices such as video tape players and juke- f actQr 0 f a video is obtained by dividing the adjusted queue 

boxes (from which movies can be loaded to disks 102) may 1U length of a video's queue by the square root of the video's 

be optionally included. relative request frequency. The adjusted queue length of a 

The program code for the video server 100 includes video's queue is the number of requests since last 

processes such as the server main control program, a video scheduling, the queue length adjusted by the number of 

scheduling program, a customer usage tracking program, defections since last scheduling. W f , the queue selection 

and conventional communications, I/O and buffer manage- factor of the i-th video queue is obtained as follows: 
ment processes. The video server 100 includes a processor 
(Le. CPU) 101 which executes the processes under control 
of the main control program and a memory buffer 105 which 
is used for the temporary storage of portions of videos (thus 
enabling some users to be served from the memory buffer 

105 rather than the disks 102). The memory buffer 105 call 0ne method of estimating the relative request frequency 

also be used to handle pause/resume requests by providing ^ to use the moving window estimate which is obtained by 

a temporary storage area tier portions of a video which counting the number of requests for each video which occur 

stream from the disk while a viewer is paused. Other than the in a movm e window of a past period (for example a window 

scheduler 106, the process may be of a conventional type 25 ofthe P 351 nour )' Smoothing techniques for forecasting can 

typically used ill VOD systems and which is described, for ^ a PP Hed t0 weighted average overpast estimates 

example in Yu, P. et al., "Design and analysis of a look-ahead (as described for example by E Hfller and O. Uebennan in 

scheduling scheme to support pause-resume for video-on- Operations Research, Second Edition (1974), Holden-day, 

demand applications", Multimedia Systems, (1995); and _ pages 522 ~ 526 )- 

Wolf, J. et aL, DASD Dancing: A Disk Load Balancing Sincc unpopular videos have lower relative request 

Optimization Scheme for Video-On-Demand Computer frequencies, the square roots of the inverse of their relative 

Systems"ACM Sigmetrics, Ottawa, Canada (1994). frequencies are larger than those of the popular videos. Thus, 

The video server 100 may be embodied using any pro- me queue selectfon factors ** obtained by applying dis- 

cessor of sufficient performance for the number of video « cnnu,iator y weighting factors to the adjusted queue lengths 

streams to be supported. For example, a small capacity video which disfavor against the more popular videos. This would 

server may be embodied using a RISC System/6000 ™ prevent the popular videos from monopolizing all the stream 

system while a larger capacity server could be embodied and farmi *g frequent batches of small sizes 

using an ES/9000 ™ system (both available from Interna- (which 15 what 000115 usm S me UJF policy), 

tional Business Machines Qsiporation of Armonk, N.Y.). « Under me mstantaneous approach the queue selection 

This disk 102 may be any conventional disk or disk army. factor of a " obtame d by multiplying its adjusted 

Hie conimunication network 104 may be, for example, a queue len 8* of * e *Meo'« queue by the time elapsed since 

fiber optic network or a conventional bidirectional cable ^ scheduling of the video. This is expressed as: 

network. The client stations 103 may each be embodied as Wi=feM)8t,. 

a v * ^. i t_. ^ 45 Although unpopular videos have lower request frequen- 
ce scheduler ^106 ^ perfonnsa number of tasks which des or shorter queues, their selection factors iicreasels the 
result m the scheduling of performances for requested time elapsed since last scheduling increases. This again 
Videos In accordance with an exemplary embodiment ofthe provides discriminatory weighting factors which disfaVor 
present invention, upon receiving video requests from the the more popular videos. 

client station 103, the scheduler (maximum selection factor 50 The impHcation of the MSF scheduling policy on the 

} »t ^ I T!; St ,. mt0 . the a J** 0fttiate ^ fairness of the system compared to the LQF policy is next 

queuejtt tracks the last scheduling ume of each video, the examined. Intuitively, the fairness of the system measures 

nurruber of defections since last scheduling, and the relative the variation in the quality of service provided across 

request frequency for each video. different videos. LQF is rather unfair to the unpopular 

Assume that there are N different videos and a separate 55 videos, because the queue for a popular video tends to build 

queue is maintained for each video. Let qi be the queue up much faster man the queue for an unpopular video. Using 

length of me i-m video queue, di be the number of defections the queue selection factor "evens out" the unfairness by 

since last scheduling at the i-th video queue, f, be the relative favoring the unpopular videos. Thus, MSF is much fairer 

request frequency of the i-th video, and St, represents the man the LQF policy. 

time since last scheduling of video i. 60 FIGS. 2A-2B are flow charts of events handled in the 

The present invention employs the notion of queue selec- MSF schedule. Each of the tasks can execute in parallel for 

tion factor and devises the MSF policy that schedules the different requests. However, the video stream scheduler is 

video with the m a ximum s election factor. The queue selec- desirably a serialization point That is to say the video stream 

tion factor is obtained by applying discriminatory weighting scheduler can be preferably invoked by only one task or 

factors to the respective queue lengths ofthe different videos 65 event at a time and executes to completion once invoked, 

where me weighting decreases as the popularity of the video FIG. 2A is a flow chart of video request handling by the 

increases. MSF scheduler. Each time a new performance request for a 
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video is made by a viewer, its arrival at the VOD system is 
detected by the scheduler at step 202. Next, at step 204, the 
scheduler determines the appropriate queue for the request 
based on the video requested and enters the request into the 
correct queue accordingly. Then, at step 206, the scheduler 
determines if there is any stream capacity available on the 
server. If there is no capacity available to service the request, 
the scheduler exits at step 208. At this point the request can 
not be scheduled until a currently running video completes 
and its associated stream capacity is freed. If the server has 
a stream capacity available, then at step 210 the scheduler 
invokes the video stream scheduling task of FIG. 3. 

FIG. 2B is a flow chart of video completion handled by 
the MSF scheduler. Completion of a video is detected by the 
scheduler at step 212. A video can complete either by 
finishing the performance through its scheduled end time or 
by all of the viewers of the video exiting the video 
(terminating the performance). At step 214, the scheduler 
frees the stream capacity by marking it as being "available" 
(the use or available status of each stream capacity is 
conventionally tracked by the video server by way of a status 
table). 

At step 2 16 the scheduler checks the request queues to 
determine if they are empty (i.e. there are no pending 
requests on any of the video queues). If the request queues 
are all empty, at step 218 the scheduler exits. Otherwise, if 
the request queues are not empty (there are waiting 
requests), at step 220 the scheduler invokes the video stream 
scheduling task of FIG. 3. 

FIG. 3 is a flow chart of video requests handled by the 
MSF scheduler to calculate queue selection factor. The 
scheduler 106 is invoked when a stream becomes available 
or a new video request arrives. At step 305, W and S are set 
equal to zero, where W tracks the maximum selection factor 
among the video queues scanned and S tracks the corre- 
sponding index of the video queue. At step 310, i is 
initialized to 1, where i is the running index to scan through 
all video queues. 

At step 315, the scheduler checks if the value of i is larger 
than the number N of video queues. This step is performed 
to determine whether all video queues have been examined 
If not, the scheduler proceeds to step 320. At step 320, if q, 
is not zero, the queue selection factor (w*) is calculated 
either at step 325 or 325a (depending on whether the steady 
state approach or the instantaneous approach is used). At 
step 330, wi is compared to W. If W, is larger, at step 340 the 
scheduler resets the value of W to track the largest queue 
selection factor scanned so far and also S to indicate that the 
i-th video queue has the largest queue selection factor among 
the first i video queues. At step 345, i is incremented by 1. 
Step 315 is then performed. 

In accordance with the description of step 315 set forth 
above, if the value of i is larger than N, then all video queues 
have been examined. At step 350, the scheduler selects video 
S to schedule and then exits at step 360. 

While the invention has been described in terms of 
exemplary embodiments, it is contemplated that it may be 
practical as outlined above with modifications within the 
spirit and scope of the appended claims. 

What is claimed: 

1. A method of scheduling a plurality of video requests, 
comprising the steps of: 

a) placing each of said plurality of video requests into a 
respective corresponding queue; 

b) de termining a queue selection factor for each queue 
based on length of each queue and defections in each 
queue; and 



1,694 

6 

c) scheduling one of said plurality of video requests based 
on said queue selection factor of each of said queues. 

2. A method of scheduling a plurality of video requests 
according to claim 1, wherein said queue selection factor is 

5 based on video request frequency of each of said plurality of 
video requests. 

3. A method of scheduling a plurality of video requests 
according to claim 1, wherein said queue selection factor is 
based on time since last scheduling in said respective 

10 corresponding queue. 

4. A method of scheduling a plurality of video requests 
according to claim 2, wherein said one of said plurality of 
video requests is scheduled having a largest queue selection 
factor. 

is 5. A method of scheduling a plurality of video requests 
according to claim 3, wherein said one of said plurality of 
video requests is scheduled having a largest queue selection 
factor. 

6. A method of scheduling a plurality of video requests 
20 according to claim 2, wherein for queue i: 
enqueue length 

dpdefections since last scheduling 
r>=relative request frequency. 
^ and the queue selection factor is: 

mi • 

30 7. A method of scheduling a plurality of video requests 
according to claim 3, wherein for queue i: 
enqueue length 

dpdefections since last scheduling 
5t(=time since last scheduling 
3 and the queue selection factor is: 

8. A method of scheduling a plurality of video requests 
40 according to claim 2, wherein scheduling occurs when a 

request is made or when a corrimunications channel becomes 
available to transmit a video signal corresponding to a 
respective one of said video requests. 

9. A method of scheduling a plurality of video requests 
45 according to claim 3, wherein scheduling occurs when a 

request is made or when a communications channel becomes 
available to transmit a video signal corresponding to a 
respective one of said video requests. 

10. Video apparatus for scheduling a plurality of video 
50 requests, comprising: 

means for receiving a plurality of video requests and for 

maintainin g a plurality of queues, each of said queues 

storing common ones of said requests 
means for determining a queue selection factor for each 
55 queue based on length of each queue and defections in 

each queue; and 
means for scheduling one of said plurality of video 

requests based on said queue selection factor of each of 

said queues. 

60 11. Apparatus for scheduling a plurality of video requests 
according to claim 10 wherein said queue selection factor is 
based on video request frequency of each of said plurality of 
video requests. 
12. Apparatus for scheduling a plurality of video requests 

65 according to claim 10 wherein said queue selection factor is 
based on time since last scheduling in said respective 
corresponding queue. 
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15. Apparatus for scheduling a plurality of video requests 
according to claim 12, wherein for queue i: 
q*=queue length 

dpdefections since last scheduling 



8 



13. Apparatus for scheduling a plurality of video requests 
according to claim 11 wherein said one of said plurality of 
video requests is scheduled having a largest queue selection 
factor. 

14. Apparatus for scheduling a plurality of video requests 
according to claim 11, wherein for queue i: 

qj=queue length 

d>=defections since last scheduling 
f Relative request frequency 
and the queue selection factor is: 



8t i =time since last scheduling 
and the queue selection factor is: 

16. Apparatus for scheduling a plurality of video requests 
according to claim 11, wherein scheduling occurs when a 
request is made or when a communications channel becomes 

xo available to transmit a video signal corresponding to a 
respective one of said video requests. 

17. A method of scheduling a plurality of video requests 
according to claim 12, wherein scheduling occurs when a 
request is made or when a communications channel becomes 
available to transmit a video signal corresponding to a 
respective one of said video requests. 
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